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TITLE Of T^E INVENTION 

WIRELESS E-MAIL SYSTEM 

5 BACKGROUND 

IMAP and POP3 are standard e-mail signalling protocols implemented by many 
"e-mail" servers. The sequence of using the signals defined in the protocols, as 
well as the content and user interface that is presented to the user, are not 
10 defined by any standard protocol. In order to present the content to the end-user 
via standard protocols such as IMAP and POP3, or via proprietary protocols such 
as Hotmail's MSP, the client must retrieve the information from the e-mail server, 
and process the data to present it in the desired format. This requires significant 
signalling, processing and memory usage on the part of the client. 

15 

For mobile wireless communication devices, where devices are constrained by 
memory size and processing capabilities, using IMAP, POP3 and SMTP (or any 
other proprietary wireline e-mail protocol) to interface directly with e-mail servers 
results in high latencies, increased battery consumption and large memory 

20 requirements. Furthermore, cellular wireless networks typically impose that radio 
channels be assigned to the wireless mobile devices for date transactions, rather 
than to make use of random access channels, which consumes network capacity. 
In addition, the above channel assignment process takes time, which inherently 
adds to latency. Ideally, a minimum amount of channel assignments should be 

25 made. Also, standard e-mail protocols are generally "chatty" and require multiple 
signal exchanges for each simple process. 

One further problem with present wireless mobile e-mail technology is that when 
the client device uses an e-mail protocol such as IMAP/SMTP, the application is 
30 not visible in the mobile operator network. Essentially, the traffic appears in the 
mobile network as data traffic, and is not distinguishable from other types of date 
traffic, such as for example web browsing. As a result mobile operators are not 
able to monitor the usage or to provide specific subscriptions based on such e- 
mail services. 

35 
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In summary, the problem is largely a specific consequence of the design of the 
IMAP and POP3 protocols, which were conceived for use over landline networks 
where latency is low, bandwidth relatively cheap and network availability high. 
Furthermore the IMAP and POP3 protocols expect a smart thick client (such as 
5 that available on a PC) that is able to process large amounts of complex data, 
which are not readily available for wireless mobile devices. 

Presently, IMAP and POP3 exist on some mobile communication devices, 
allowing the client device to retrieve and transmit e-mails directly with the e-mail 
10 server. Additionally, web-portal based e-mail, such as that provided by Yahool 
and Hotmail, are also available on wireless mobile devices using WAP browsers. 

Other mobile e-mail solutions use synchronization as a method for ensuring that 
the data on the mobile device and remote server are consistent. 

15 Synchronization allows for use in offline mode, where changes to the data set on 
the client or on the server can happen independently, and updates to both data 
sets are made during the synchronization procedure. For mobile 
communications systems that allow for an "always-on 0 connection, changes to 
the data set that are made in the mobile device may be reflected immediately In 

20 the remote server, eliminating the need for synchronization. 

Finally, an alternative solution for wireless e-mail is disclosed in US Patent No. 
6,701,378, in which e-mails are received by a redirector software, and forwarded 
immediately to the mobile device based on filtering rules. These filtering rules, 
25 specific to each mobile device, require persistent storage in the redirector 
software. This system also requires that the e-mail server forwards each e-mail 
to the wireless redirector software. 

Consequently, prior art wireless mobile e-mail systems' can be divided into the 
30 following two categories: 

1) Enterprise focused e-mail access using IMAP, POP3 or proprietary 
means to grant access to enterprise e-mail. This solution is typically costly 
on a monthly bases and requires a relatively expensive handset. 
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2) Simple and limited WAP based e-mail access for consumers and 
other users. 

SUMMARY OF THE INVENTION 

5 

To address the above and other drawbacks of the prior art wireless e-mail 
systems, a novel wireless e-mail system is provided which allows for a wireless 
mobile device to support a thin client for e-mail functions, with most of the 
processing offloaded to an external platform that is not significantly constrained 
10 by memory, processing capability or power supply. 

The client initiates the request in the format that allows it to retrieve the 
information it requires to be displayed in a single requestfresponse pair. (This is 
in contrast to standard e-mail protocols which require multiple transactions and 

15 significant processing on the part of the client to extract the required information). 
Additionally, the client device is not required to maintain a persistent session with 
the e-mail server, or the gateway, in order to initiate subsequent transactions, as 
is required by IMAP or POPS. Each request is self-contained, eliminating any 
need for user-specific information to be stored on the gateway, including filters. 

20 The system performs a relevant transfer of a small subset of the data as 
requested by the user. A single sessionless request/response pair is used for 
each of those transactions initiated by the client. 

Furthermore, the gateway may contain configuration options to allow for different 
25 system behaviours based on mobile operator preferences or specific handset- 
type limitations. The configurable options may comprise: 

0 The number of e-mails to include per page view of the mailbox (e.g. 
10 e-mails per page view). 

30 

ii) Which fields to include per page view of the mailbox (e.g. subject, 
from, date); and 

lii) The maximum size of an e-mail message to download at a time . 
35 (e.g. 10 kB). 
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Other objects, advantages and features of the present invention will become 
more apparent upon reading of the following non-restrictive description of 
illustrative embodiments thereof, given by way of example only with reference to 
5 the accompanying drawings. 

RBIPP DESCRIPTION OF TH E DRAWINGS 

Reference will now be made to the accompanying drawings, showing by way of 
1 0 illustration an illustrative embodiment of the present invention, and in which: 

Figure 1A schematically illustrates a wireless e-mail system in accordance with 
an illustrative embodiment of the present invention; 

15 Figure 1B schematically illustrates a wireless e-mail system in accordance with 
an alternative illustrative embodiment of the present invention; 

Figure 2 schematically illustrates the communication interfaces employed in the 
wireless e-mail systems of Figures 1A and 1B; 

20 

Figure 3 presents a block diagram providing a functional overview of the E-mail 
Gateway of Figures 1A and 1B in accordance with an illustrative embodiment of 
the present invention; 

25 Figure 4 presents a flow chart of a high-level sequence of events of a single 
wireless e-mail transaction between an end user, an e-mail gateway and an e- 
mail server in accordance with an illustrative embodiment of the present 
invention; and 

30 Figure 5 presents a flow chart of a possible implementation of an e-mail thin 
client in accordance with an Illustrative embodiment of the present invention. 

PPSCRIPTION OF THE ILLUSTRATIVE EMBODIMENTS 

35 
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Referring now to Figure 1A, a wireless e-mail system, generally referred to using 
the numeral 10, and in accordance with an illustrative embodiment of the present 
Invention, will now be described. The wireless e-mail system 10 generally 
comprises the following components: 

5 

A) At least one end user wireless mobile device, as in 12, such as 
GSM mobile phones and the like, or any other wireless device including 
palm and pocket PCs, PDAs, etc; 

10 B) A mobile operator network 14; 

C) An e-mail gateway 16 that has connectivity to the mobile operator 
network 14 and the e-mail server 18; and 

15 D) At least one e-mail server, as in 18, from at least one e-mail service 

provider, as in 20. 

Each mobile device 12 will generally comprise ROM, RAM, a processor, a 
removable/reusable battery as well as a user interface, Input means (e.g. keypad, 

20 stylus, touch screen, voice recorder) and display means (color or monochrome 
display or displays) for interfacing with the user and providing visual access to e- 
mail and other communicated and stored information. The wireless device 12 will 
also comprise wireless connection capabilities, such as GSM, cdma2000, UMTS 
or other such capabilities, for wirelessly connecting to and communicating with a 

25 mobile network. Furthermore, in order to support the present wireless e-mail 
system, each mobile device 12 implements an additional e-mail thin client 22 
typically in the form of a software program residing on each wireless mobile 
device 12. The primary functions of the e-mail thin client 22 are to: 

30 A) Interface with the end user to allow for user input and to display the 

requested e-mail information; 

B) Use a specific interface (Interface A of Figure 2 further described 
hereinbelow) to request services from the e-mail gateway 16; and 

35 
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C) Provide a common implementation base for different user 
interfaces from the different e-mail service providers 20. 

The mobfle operator network 14 is basically any network supporting any type of 
5 wireless data communication such as GSM, cdma2000, UMTS, or other such 
systems. The mobile operator network 14 provides the wireless data 
communication system (dashed lines) between the various mobile wireless 
devices 12 and the landllne network (solid lines) connecting the various e-mail 
servers 18 of each service provider 20. 

10 

The e-mail service providers 20, and respective e-mail servers 18, support 
standard or proprietary e-mail signalling protocols such as IMAP, POP3, 
Hotmail's MSP, or other such protocols for the management and retrieval of e- 
mails, as well as standard or proprietary signalling protocols, such as SMTP, 

15 Hotmail's MSP or other such protocols for sending e-mails. E-mail service 
providers may include, but are not limited to, Yahool Mail, AOL Mail, Hotmail, or 
any other common consumer-based ISP e-mail servers, web-based e-mail 
providers or corporate e-mail providers. Basically, the e-mail servers 18 in the 
illustrated embodiments operate as they would with standard communications 

20 established by prior art wired and wireless devices. Yet while the e-mail client 22 
may be implemented using a standard protocol (for example communicating over 
HTTP), its implementation will be executed in a unique way. For example, if a 
mail is deleted by the end user, It may or may not be required that the client 22 
move the e-mail to the "Deleted Items" folder. The signals used in the protocol 

25 are standard, but the sequence of the signals and the overlying structure of the e- 
mail client 22 may be unique depending on the implementation. . 

The primary functions of the e-mail gateway 16 are to offload processing and 
signalling for e-mail access from multiple wireless mobile devices, as in 12, onto 

30 an external platform that is part of the wired network (solid lines In Figures 1A, 
1B, 2 and 3). and to allow the mobile network operator 16 to monitor usage of the 
specific e-mail service. The gateway furthermore allows the wireless mobile 
devices 12 to Implement a thin client 22 that can support multiple user interfaces 
of the different e-mail service providers 20. The main functions of the gateway 16 

35 include: 



-6- 



CA 02493907 2005-01-24 



(A) Processing requests from the e-mail thin client 22 of each wireless 
mobile device 12; 

5 (B) Translating the standard e-mail protocols based on implementation 

of a specific e-mail service (e.g. Yahoo vs. AOL); 

(C) Generating billing reports and billing data; 

1 0 (D) Monitoring traffic and generating traffic reports; 

(E) Allowing for the mobile operator to configure settings In a particular 
deployment or for a particular handset type. 

15 In particular, referring to function (E) above, the gateway may contain 
configuration options to allow for different behaviour based on mobile operator 
preferences or on specific handset-type limitations. The configurable options may 
comprise: 

20 (0 The number of emails to include per page view of mailbox (e.g. 1 0). 

(ii) Which fields to include per page view of mailbox (e.g. subject, from, 
date); and 

25 (Hi) The maximum size of an e-mail message to download at a time 

(e.g. 10 kB). 

Adding reference to Figures 2 and 3, and in accordance with an illustrative 
embodiment of the present invention, the e-mail gateway 16 generally serves as 

30 a bridge between the wireless devices 12 and the service providers 20. As will be 
discussed in greater detail below, the gateway 16 must process requests 
incoming from the client 22 of devices 12 using a first interface! that is Interface A 
of Figure 2, and communicate those requests to the e-mail servers 18 of the e- 
mail service providers 20 using a second interface, Interface B. Consequently, as 

35 presented in Figure 3, incoming requests from the client 22 are first processed by 
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the Interface A processor 26, and expedited to a requested e-mail seiver 18 
using Interface B. Once the information requested by the client 22 is gathered 
using Interface B (possibly through multiple transactions as described further 
hereinbelow) and processed by the Interface B processor 28, it is returned to the 
5 client 22 using Interface A. 

As will be described further hereinbelow, Interface A is designed to provide a 
simple and unique interface using single self-contained request/response pairs 
30, for example over HTTP, between the wireless devices 12 and the gateway 
10 16. These request/response pairs 30 also allow for the piggybacking of requests 
In a single self-contained pair. For example, both a request for the Inbox view as 
well as a request for the list of folders may be combined in a single request to the 
gateway 16. 

15 Conversely, Interface B is essentially any interface supported by the various e- 
mall providers, namely using such signalling protocols as IMAP, SMTP, POP3 
and other common or proprietary protocols, and may use multiple transactions 32 
for a single request 34, as common with such protocols. Necessarily, the 
implementation of the Interface B processor 28 is largely dependent on the 

20 particular e-mail service provider 20 the gateway 16 is requested to interact with. 

In addition to its Connection Management function 36, generally described 
hereinabove, the gateway 16 will also provide for event monitoring and reporting 
38, billing data generation 40, and an interface to the authorization and 

25 accounting systems of the mobile operator 42. Since the gateway 16 must be 
used to complete wireless e-mail transactions requested by the end user, the 
present e-mail system 10 will provide visibility in the mobile operator network 14, 
allowing e-mail traffic to be distinguishable from other data traffic, such as for 
example web browsing. In prior art wireless e-mail systems using IMAP or POP3 

30 protocols, such transparency is not provided to the mobile operator, limiting billing 
and subscription capabilities in those systems. 

Essentially, the novel wireless e-mail system 10 of the illustrative embodiments of 
the present invention allows for a wireless mobile device 12 to support a thin 
35 client 22 for e-mail functions, with most of the processing offloaded to an external 
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platform, such as gateway 16, that is not significantly constrained by memory, 
processing capability or power supply (common restrictions in portable wireless 
devices as in 12). In the illustrative embodiment of Figure 1A, the gateway 16 is 
illustrated as being an extension of the mobile operator network 14. In the 

5 alternative embodiments illustrated in Figure 1B, the e-mail gateways 16 2 and 16a 
of e-mail wireless system 10' are illustrated as extensions to e-mail servers 18 4 
and 18 6 of service provider network 43 and Corporate Network 44 respectively. In 
both embodiments (10 and 10'), processing is substantially offloaded to the 
gateways 16, independent of their specific position within the e-mail systems 10 

10 and 10\ Yet, as the gateways 16 2 and 16 3 are coupled to the respective e-mail 
servers of service provider network 43 and corporate network 44, the monitoring 
and billing features of the gateways I62 and 16 3 will inherently be respectively 
interfaced with the service provider network 43 and the corporate network 44 
instead of with the mobile operator network 14. 

15 

Referring now to Figures 1A and 2, and in accordance with an illustrative 
embodiment of the present invention, the wireless e-mail system 10, as 
mentioned hereinabove, makes use of two distinct interfaces to complete each e- 
mail transaction: Communications between the client 22 and the gateway 16 use 
20 Interface A, whereas communications between the gateway 16 and the e-mail 
servers 18 use Interface B. 

Interface A is a request/response interface with the request generally originating 
from the client 22. Using Interface A the client initiates a request in a format that 

25 allows it to retrieve the information it requires to be displayed in a single 
request/response pair 30. Unlike standard e-mail protocols which require multiple 
transactions and significant processing on the part of the client to extract the 
required information, Interface A allows for a single transaction 30 between the 
client 22 and the gateway 16 for each user request. As each request is self- 

30 contained, there is no need for user-specific information, such as filters, to be 
stored on the gateway 16. The system performs a transfer of a small subset of 
the data as requested by the user using a single sessionless request/response 
pair 30 over HTTP for each of the transactions initiated by the client 22. 
Consequently, the client device Is not required to maintain a persistent session 

35 with the e-mail server 18, or the gateway 16, in order to initiate subsequent 
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transactions, as is required by IMAP or POP3. Furthermore, each time the client 
22 is launched, it will retrieve the most recent information via Interface A, which 
means the client 22 is not required to keep persistent storage of the user data (e- 
mail messages) in memory for extended periods of time. Subsequently, data can 
5 be fetched just-in-time for each user request. On the other hand, although no 
sessions are required between the client and the gateway for communication 
purposes, a session may optionally be used to allow for additional security, for 
example use of HTTPS between the client and the gateway. 

10 Specifically, Interface A is a request-response interface, wherein the request, as 
mentioned hereinabove, generally originates from the wireless thin e-mail client 
22. The client request commands are generally grouped into two categories: one 
for content retrieval (see Table 1 hereinbelow), and the other for sending or 
modifying content (see Table 2 hereinbelow). Furthermore, as discussed 

15 hereinabove, Interface A also allows for the piggybacking of requests in a single 
request/response pair. In practice, Interface A may be implemented using an 
XML structure, though other similar structures may also be used. Specific 
examples of such commands will be discussed further hereinbelow with 
reference to Tables 1 and 2. 

20 

As for communications between the gateway 16 and the various e-mail servers 
18, Interface B is used. Essentially, Interface B is any interface supported by the 
various e-mail providers 20, namely using such signalling protocols as IMAP, 
SMTP, POP3 and other common or proprietary protocols. In other words, if the 

25 user seeks e-mail connectivity with an e-mail service provider 20 using 
IMAP/SMTP as signalling protocols, the gateway will configure the client request 
provided through Interface A such that Interface B also uses IMAP/SMTP as 
signalling protocols. Consequently, though communications between the client 22 
and the gateway 16 through Interface A use single request/response pairs 30, 

30 communications between the gateway 16 and the various service providers 20 
through Interface B may include multiple transactions 32 for a single request 34. 
Since these transactions 32 are completed over a landline network, latency and 
bandwidth concerns common with wireless networks are less of an issue with the 
present configuration. 

35 
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In Tables 1 and 2, the main content of Interface A is shown. The client request 
commands are grouped into two categories: one for content retrieval (Table 1), 
and the other for sending and modifying content (Table 2). Each request results 
in a response (not shown). Necessarily, the content of Interface A may include 
5 other components not listed here, without departing from the general concept 
provided by the wireless e-mail system 10. 



Table 1: Client Requests used for Retrieving Content 



Request ! 


Main Record Filter 


Main Field Filter 


Comments 


Get/Message Request 


Message Identity 


One or more of: 

Attachment 

FuOtext 

Partial text (referece 
by kB) 

(or any subftetds from 
list directly below) 


Use to retrieve an email message 
or multiple ema3 messages 


Get/Mailbox View 


Mailbox Identity 
One of: 
Page Number 
Number of Pages 


One or more of: 

To 

From 

Subject 

Date 

Size 

cc 

bcc 

/Read 

/Answered 

Attachment Flag 

Attachment Name(s) 

Partial Text 


Use to retrieve a list of messages in 
a mailbox page 


Get/Account View 


One of: 
Full list 
System list 


One or more of: 
Folder Capabilities: 

Read/ 
Write/Delete/Rename 
Total number of 
messages 
Total unread 
messages 


Used to retrieve a list of folders 
(mailboxes), and their capabilities 


Get/Address 


One of: 
Full list 

Letter range (e.g. A- 
C) 

Search field 




Used to retrieve an address 



10 



15 
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Table 2: Client Requests used for Sending and Modifying Content 



Request 


Main Content of Message 


Comments 


Put/Send 


Message Header and Content 


Used to send new message i 


Put/Forward 


Message Identity, Header and 
Content 


Used to forward a message 


Put/Reply 


Message Identity, Header and 
Content 


Used to reply to a message 


Put/Notification Rag 


On/Off Setting 


Sent to server if interface exist for email notification 
and ability to turn email notification on/off 


Add/Message 


Message Header and Content 


Used to add a message to a mailbox (e.g. store 
draft) 


Replace/Message 


Message Identity and new 
mailbox name 


Used to move a message to a new mailbox 


Delete/Message 


Message Identity 


Used to delete a message 


Delete/Account View 


Mailbox Identity 


Used to delete a mailbox (folder) 


Put/Account View 


Mailbox Name 


Used to create a new mailbox (folder) 


Reolace/AccourrtView 


Old and new mailbox names 


Used to Rename a mailbox (folder) 



As mentioned hereinabove, Interface A also includes a "response 0 primitive, 
which occurs for each request generated by the client 22. Finally, while a single 
request-response transaction 30 is required and used through Interface A to 
10 communicate with the gateway, multiple transactions 32 through Interface B 
using IMAP/SMTP may be used between the gateway 16 and the service 
provider 20 to gather all of the information requested by the client 22 without 
generating any latency and/or bandwidth concerns in the system 10. 

15 Referring now to Figures 1A, 1B and 4, and in accordance with an 'illustrative 
embodiment of the present invention, a high-level sequence of events of a single 
wireless e-mail transaction between an end user, an e-mail gateway 16 and an e- 
mail server 18 using the wireless e-mail system 10 is presented. 

20 The wireless e-mail transaction starts with a user input at step 50; 

In the following step 52, the client 22 of the user's wireless device 12 requests 
the gateway 16 to either fetch, process, or send a specific set of information 
(including forward and reply requests) based on the user action of step 50 using 
25 the protocol of Interface A. This request is sent over the wireless network as a 
single self-contained request; 

-12- 
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In step 54, the gateway 16 communicates with the e-mail server 18 of the 
selected e-mail service provider 20, service provider network 44 or corporate 
network 46, and compiles the requested information from the e-mail server 18 
5 using the protocol of Interface B (e.g. POP3, IMAP, SMTP, MSP). Unlike in step 
52, communications in this step may include multiple transactions 32 as 
communications are executed over a landllne connection and are thus not limited 
to bandwidth and latency issues experienced using wireless connections; 

10 In step 56, the gateway 16 sends the requested information to the client 22 in a 
single transfer, again using Interface A over the wireless network, completing the 
single request/response pair 30; 

In step 58, the requested information is presented to the user. 

15 

As will now be apparent to a person of skill in the art, the wireless e-mail system 
10 described herein allows for low cost thin clients, as in 22, to access e-mail 
over a wireless network. The thin client 22 can be branded to reflect the look and 
feel of the e-mail service provider 20 the user has selected (for example Hotmail, 
20 Yahoo! mail, AOL mail or other such e-mail services). The client 22 on the mobile 
device 12 requires only minimal resources, but can still provide a "PC-like" 
experience to the end user that is far better than what can be offered over WAP, 
which has until now been the typical approach to e-mail on low end and mid 
range devices. 

25 

Referring now to Figure 5, a flow-chart presenting a possible implementation of 
an e-mail thin client in accordance with an illustrative embodiment of the present 
invention is presented. Once the user has launched the e-mail application, 
selected the desired e-mail service and entered appropriate user ID/password 

30 information, the gateway is requested to fetch a first set of information (e.g. first 
page of the Inbox) for display to the user. The user may then select from a 
plurality of requests/options (e.g. open e-mail, delete e-mail, compose new e- 
mail, view folder, view next page, etc..) that will be communicated to the 
gateway 16 and subsequently to the e-mail service provider 20. For each self- 

35 contained client request, the gateway 16 gathers the requested information or 

-13- 
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response from the service provider, and transfers the data to the mobile client in 
a single response for display to the user. Furthermore, a minimum of necessary 
data/information is downloaded to the client for each request. For example, when 
a user requests that an e-mail be forwarded, or that a reply includes the original 
5 e-mail, the gateway is capable of regenerating the original e-mail without 
requiring that the client download the full original e-mail over the wireless 
network. 

A thin client approach as described herein allows offloading of processing and 
10 signalling to a landline system that is less constrained by memory size or battery 
life. Consequently, the wireless e-mail system 10 reduces latencies and battery 
consumption as less signalling and processing are required of the mobile device 
12. Furthermore, the use of a single Just-ln-tlme request/response pair for each 
query makes much more efficient use of the wireless interface thus minimizing 
15 radio use and fragmentation. The resulting traffic flow is consistent with user 
requests, queries and general use of the system, making service costs 
transparent and understandable. Finally, the system 10 allows for monitoring and 
billing of the e-mail service by the mobile operator 14. 

20 While this invention has been described with reference to the illustrative 
embodiments, this description is not intended to be construed to a limiting sense. 
Various modifications or combinations of the illustrative embodiments, as well as 
other embodiments of the invention, will be apparent to persons skilled in the art 
upon reference to the description. It is therefore intended that the described 

25 invention encompass any such modifications or embodiments. 
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WE CLAIM: 

1 . A wireless e-mail system comprising: 
a wireless device comprising a client; 
a server; and 

a gateway comprising a first interface and a second interface, said client 
communicating with said gateway using said first interface and said 
server communicating with said gateway using said second interface; 

wherein when said client communicates using said first interface a single 
self-contained request for a set of information to said gateway based 
on a user action, said gateway compiles said set of information from 
said e-mail server using said second interface, and sends a single self- 
contained response containing said set of information to said client 
using said first interface;wherein said request and said response form 
a sessionless request-response pair. 
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Figure 1B 
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Figure 2 



CA 02493907 2005-01-24 




CA 02493907 2005-01-24 




Input from User 



Client device requests gateway 
to fetch information based on 
user action using protocol of 
Interface A 



Gateway compiles requested 
information from email server 
using Interface B (IMAP. POP3) 
This may include muttipla 
transactions 



Gateway sends information to 
client in a single transfer 



Output to User 




Figure 4 
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